With the increasing prevalence of smart phones and mobile computing devices having communications capability, many communications networks are becoming overloaded. It is often difficult to establish communication through a wireless network because its resources are completely encumbered by the network load. “Device to device” direct communication can mitigate this problem by offloading what would otherwise be network traffic onto direct communication paths between devices.
This alternative approach raises issues related to communication security. The devices each must authenticate the other with respect to their cellular identities. Any security association (that is, secure key encrypted signaling) between devices must continue to comply with lawful interception requirements.
One technique for creating a secure channel between two devices involves only the two devices that desire to communicate. Normally the devices must be in proximity to one another (such as Bluetooth devices, or connected via universal serial bus (USB) cable, Infrared link or serial cable link). The devices require user interaction, for example inserting a shared secret (e.g., a cryptographic key), handshaking the phones together, or otherwise establishing some type of link between them through user manipulation. These techniques do not satisfy the lawful interception requirement, since the established secret is not available to the lawful interception agencies.
Another technique for creating a secure channel between two devices involves a trusted third party. This technique includes provisioning the devices with shared keys or trust certificates that are accessed and used on demand by the user(s). Communications 3GPP™ Technical Specification TS 33.259 describes using the NAF Key Center but does not specify how the Remote Device and the key center can mutually authenticate each other. TS 33.259 was written with the assumption that the Remote Device would be, for example, a personal computer (PC).
Referring to FIG. 3, an architecture is shown for supporting this technique to establish a secure channel between a universal integrated circuit card (UICC) Hosting Device 40 and a Remote Device 42 connected via a local interface 44 for the purpose of protecting the communication between the devices. The FIG. 3 architecture is that specified in 3GPP™ TS 33.259 (v. 10.0) for key establishment which is incorporated in its entirety as if fully set forth herein.
With continued reference to FIG. 3, the local interface 44 between the UICC Hosting Device 40 and the Remote Device 42 is normally accomplished via a short-range radio frequency (RF) connection (e.g., Bluetooth or infrared (IR)) or a wired link (e.g., USB cable or serial cable). The object of the key security process is to arrive at a local key that both the UICC Hosting 40 and Remote Device 42 share so that they can exchange data securely.
In general, the Remote Device 42 requests parameters from the UICC Hosting Device 40 that are necessary to the ultimate derivation of the shared local key (Ks_local_device) that will facilitate secure communication. These parameters include an NAF-ID and a bootstrap transaction identifier (B-TID). The Remote Device 42 and the NAF Key Center 46 establish a communication link via a secure transport layer security pre-shared key (TLS-PSK) tunnel. The Remote Device 42 sends a request to the NAF Key Center 46 for a shared key (Ks_local_device).
The NAF Key Center 46 calculates the new shared local key using the parameters provided by the Remote Device 42 and returns a message containing the value of the shared local key Ks_local_device and its lifetime. The Remote Device 42 stores the shared local key and sends a message to the UICC Hosting Device 40 that the key has been established. The Remote Device 42 then sends the same parameters to the UICC hosting device 40 that it provided to the NAF Key Center 46 together with the new shared local key lifetime. The shared local key (Ks_local_device) itself is never exchanged between the Remote Device 42 and the UICC device 40.
The UICC Hosting Device 40 uses the parameters from the Remote Device 42 to derive the local shared device key Ks_local_device and store it locally. The UICC Hosting Device 40 signals the Remote Device 42 that the key verification is successful. Secure communication between the two devices proceeds using the shared local key.
Should the Remote Device 42 have no network connectivity so as to access the NAF directly, its communication may be routed through the UICC Hosting device 40 to the NAF 46 (“tethering”). The protocol for deriving the shared local key proceeds as described above.
This protocol assumes that the Remote Device is a personal computer or other computing device. Therefore the protocol does not provide a way for the Remote Device and the NAF key center to mutually authenticate each other, since no technical assumption on the available security mechanisms, e.g. in a PC, could be made during the writing of the standard.
The “UICC hosting device” of FIG. 3 is too narrow a reference for evolving communication devices, which include, for example, mobile (cellular) phones, various computing devices, personal digital assistants (PDAs), notebooks, tablets and the like. Each of these devices may be provided with secure key derivation features, such as, for example, SIM, ISIM, USIM, ICC_ID, C-SIM, RUIM, or SIP Digest mechanism applications (collectively, “security foundation”). These are baseline key derivation features and may be hosted by a UICC, a SIM card, embedded SIM capability, or other forms of secure element (e.g., ARM TrustZone Chip or other secure chip). Even virtualization of the secure element in an existing processor is possible. For these reasons, in the remainder of this description, the “UICC Hosting Device” of FIG. 3 will be replaced by the more generic “Secure Cellular Device” to encompass the broader universe of secure communications devices.